| TWiki . EBR . EbrNode |
An EbrNode is a client / server network process (software) that can accept, process and route EbrMessages. In addition it may offer EbrServices available to other EbrNodes within the network.
EbrNodes can act in a peer-to-peer fashion, sending data directly from one EbrNode to another, or behave in the traditional Local->National->EBR Gateway Node routing manner. Note that in the latter case the EbrNetwork now permits bi-directional communication, allowing an EbrGateway to send a request back to a EbrNode asynchronously.
Communication between EbrNodes is via the EbrProtocol.
Once installed, the CoreSoftware provides all the routing logic an EbrPartner requires to become an active EbrNode. For LocalDistributorNode and NationalDistributorNodes, no extra programming or software development is necessary unless they want to implement CustomServices.
There are three different NodeTypes:
Some NationalDistributorNode operators act as resellers of company information. They may act in partnership with one or more LocalDistributorNode to distribute company information within a country.
The LocalDistributorNode is a client/server process that is a server to any User Interface application and a client to the NationalDistributorNode for forwarding EbrMessages.
All EbrMessages forwarded by the LocalDistributorNode go directly to the NationalDistributorNode. The network details of the NationalDistributorNode is contained in the configuration file for that installation. LocalDistributorNode details are regarded as a private arrangement between itself and its controlling NationalDistributorNode and are not stored at the ServiceNode.
The DataLayer stored at the LocalDistributorNode can be shared with a UI application, allowing the UI access to the DynamicSystemTables to present end-users with an accurate status of the EbrNetwork and the EbrServices it offers.
Through the LocalDistributorNode interface, UI developers will also have access to the EbrSchema and FormsXml files, which could assist dynamic building of HTML forms and subsequent presentation of results and to the EBR table codes, permitting transformation of messages into the correct language selected by the end-user.
A NationalDistributorNode is typically the sole distributor of company information in a country. It may optionally distribute this information to one or LocalDistributorNode.
This is a client/server process that is a server to the LocalDistributorNode (accepting EbrMessage requests) and a client to NationalGatewayNodes (forwarding EbrService requests). All messages from LocalDistributorNodes under the control of a NationalDistributorNode will be routed through the NationalDistributorNode software and forwarded to the appropriate NationalGatewayNodes.
The list of available LocalDistributorNode installations allowed to contact the NationalDistributorNode is part of the NationalDistributorNode configuration.
This NationalDistributorNode will detect requests for cross-country searches and forward them to the appropriate NationalGatewayNode server(s) returning the results in a single EbrMessage for parsing and presentation by the EbrMessage originator.
The NationalDistributorNode software will map each destination ID to the network address specified in its cached DynamicSystemTables copy.
It shall be possible to plug a UI implementation directly into the NationalDistributorNode software, bypassing a LocalDistributorNode installation. In such a case, the message journey condenses into a route of UI->ND->NG/IP.
The NationalGatewayNode acts as a bridge between the data held at the InformationProvider and distribution of that data to external entities, e.g. Orchid can be thought of as a NationalGatewayNode to Companies House.
This is a client/server process. It serves the NationalDistributorNode (accepting EbrService requests) and is a client to EbrGateways (when in RemoteServices mode), providing access to the actual InformationProvider data.
NationalGatewayNode operators publish the details and availability of their services via the AdminSite. EbrOperators may choose to develop their EbrServices using the same Platform Layer (Java, etc.) supplied by theNationalGatewayNode CoreSoftware or via their own preferred toolkits.
Each EbrNode must have an unique ID that is registered together its network and Service details at the AdminSite.
The Node ID has the format XXX_YY_ZZZZZZ, where XXX
is the 3 digit ISO country code that the Node belongs to, YY is the
NodeType
(LD/ND/NG) and ZZZZZZ is a free format "nickname" string chosen by
the Node operator to identify the Node.
For example,
GBR_NG_orchid
The list of all EbrNodes (except LocalDistributorNode - there are not required to register their details) can be obtained via a EbrMessage to the ServiceNode requesting the DST (Dynamic Service Tables) Data Layer component. This returns a set of XML files containing all the information about other Nodes and Services available within the G2 network.
The Core Software uses the contents of the tables within the DST when scanning Messages for routing information, matching NodeId with the network details (host name, port number, etc.).
Once you have installed your EbrNode you must register it at the AdminSite (even if you do not support any EbrServices initially). The information you register must match the details you have supplied in your EbrNode configuration file.
EbrMessages can consist of one or more EbrMessageParts. Any EbrNode that receives a MultiPartEbrMessage will always act as a demultiplexer and forward each EbrMessagePart individually to its destination, along with the EbrMessageGlobalHeader, before returning a single MultiPartEbrMessage reply containing all the reply EbrMessageParts.
This greatly simplifies the task of EbrGateway developers who will only ever receive a Message consisting of a single part.
For each EbrMessagePart within the MultiPartEbrMessage, the EbrNode creates a new threaded client connection that performs the request. When all threads have returned (or the thread timeout limit is reached) the EbrNode concatenates the returned replies into one single Multipart Message.
Two logs will be appended to for each EbrMessage received by a EbrNode installation, one for the EbrMessageGlobalHeader, one for the EbrMessagePartHeaders.
Basic EbrMessage
information will be stored locally in $INSTALL_DIR/logs/message.log
and $INSTALL_DIR/logs/part.log as CSV files for easy import into
spreadsheet or database applications. Administration (e.g. emptying, archiving,
rotation, etc.) of the logs will be left to the EbrOperator.
The latest message and part information will be written by the Core Software
to $INSTALL_DIR/logs/message.log.latest and
$INSTALL_DIR/logs/part.log.latest .After a configurable interval
has elapsed the contents of these files will be sent in an EbrMessages to a
log processing service hosted at the ServiceNode.
If the call to the ServiceNode
returns success, the contents of the latest log files will be appended to the
main $INSTALL_DIR/logs/message.log /
$INSTALL_DIR/logs/part.log and zeroed. If the call fails,
message.log.latest and part.log.latest must
not be emptied. The log contents must be preserved until the
next schedule log update. EbrOperators
must not to alter the contents of the "latest" files.. The
entire process ensures that only the latest set of messages (since the last log
update) are transmitted to the ServiceNode for
statistical purposes.
In addition to this elementary logging, EbrOperators may choose to enable full request and reply logging. In this situation, the full message body for every request and reply will be stored as a single, unique file in the appropriate directory, with the transaction ID of the message as its filename.
This feature will be of most benefit during testing and debugging phases, although some countries with a legal obligation to store the exact request / response made by a client may find it of great value.
----- Revision r1.8 - 24 Oct 2003 - 12:56 GMT
- MartinWood
|